Add the RPMH clocks present in Kaanapali SoC.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20251209-gcc_kaanapali-v3-v5-2-3af118262289@oss.qualcomm.com
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>

Add the TCSR clock controller that provides the refclks on Kaanapali
platform for PCIe, USB and UFS subsystems.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20251209-gcc_kaanapali-v3-v5-3-3af118262289@oss.qualcomm.com
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>

…pali

Add support for Global clock controller for Kaanapali Qualcomm SoC.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20251209-gcc_kaanapali-v3-v5-4-3af118262289@oss.qualcomm.com
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>

Recent QCOM PLLs require the CAL_L field to be programmed according to
specific hardware recommendations, rather than using the legacy default
value of 0x44. Hardcoding this value can lead to suboptimal or incorrect
behavior on newer platforms.

To address this, introduce a `cal_l` field in the PLL configuration
structure, allowing CAL_L to be set explicitly based on platform
requirements. This improves flexibility and ensures correct PLL
initialization across different hardware variants.

Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20251125-kaanapali-mmcc-v2-v2-1-fb44e78f300b@oss.qualcomm.com
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>

… EKO_T PLL

Add clock ops for Pongo EKO_T PLL, add the pll ops for supporting
the PLL.

Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20251125-kaanapali-mmcc-v2-v2-2-fb44e78f300b@oss.qualcomm.com
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>

…n PLL

Add clock ops for Rivian ELU and EKO_T PLLs, add the register offsets
for the Rivian ELU PLL. Since ELU and EKO_T shared the same offsets and
PLL ops, reuse the Rivian EKO_T enum.

Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20251125-kaanapali-mmcc-v2-v2-3-fb44e78f300b@oss.qualcomm.com
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>

…ontroller

Document device tree bindings for display clock controller for
Qualcomm Kaanapali SoC.

Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20251125-kaanapali-mmcc-v2-v2-4-fb44e78f300b@oss.qualcomm.com
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>

Update the compatible and the bindings for CAMCC support on Kaanapali
SoC.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20251125-kaanapali-mmcc-v2-v2-5-fb44e78f300b@oss.qualcomm.com
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>

Add device tree bindings for the video clock controller on Qualcomm
Kaanapali SoC.

Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Link: https://lore.kernel.org/r/20251125-kaanapali-mmcc-v2-v2-6-fb44e78f300b@oss.qualcomm.com
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>

…Controller

Add bindings documentation for the Kaanapali Graphics Clock and Graphics
power domain Controller.

Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Link: https://lore.kernel.org/r/20251125-kaanapali-mmcc-v2-v2-7-fb44e78f300b@oss.qualcomm.com
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>

… Kaanapali

Support the clock controller driver for Kaanapali to enable display SW to
be able to control the clocks.

Link: https://lore.kernel.org/r/20251125-kaanapali-mmcc-v2-v2-8-fb44e78f300b@oss.qualcomm.com
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>

…or Kaanapali

Add support for the Camera Clock Controller (CAMCC) on the Kaanapali
platform.

The CAMCC block on Kaanapali includes both the primary camera clock
controller and the Camera BIST clock controller, which provides the
functional MCLK required for camera operations.

Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Link: https://lore.kernel.org/r/20251125-kaanapali-mmcc-v2-v2-9-fb44e78f300b@oss.qualcomm.com
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>

Enable Kaanapali video clock driver for video SW to be able to control
the clocks from the Video SW driver.

Link: https://lore.kernel.org/r/20251125-kaanapali-mmcc-v2-v2-10-fb44e78f300b@oss.qualcomm.com
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>

Support the graphics clock controller for Kaanapali for Graphics SW
driver to use the clocks. GXCLKCTL (Graphics GX Clock Controller) is a
block dedicated to managing clocks for the GPU subsystem on GX power
domain. The GX clock controller driver manages only the GX GDSC and the
rest of the resources of the controller are managed by the firmware.

Link: https://lore.kernel.org/r/20251125-kaanapali-mmcc-v2-v2-11-fb44e78f300b@oss.qualcomm.com
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>

Add the PMU node for talos platforms.

Link: https://lore.kernel.org/all/20251217092057.462-1-yuanjie.yang@oss.qualcomm.com/
Signed-off-by: Yuanjie Yang <yuanjie.yang@oss.qualcomm.com>

…ge during STOP handling

Currently v4l2_m2m_ioctl_{de,enc}coder_cmd is being invoked during STOP
command handling. However, this is not required as the iris driver has
its own drain and stop handling mechanism in place.

Using the m2m command API in this context leads to incorrect behavior,
where the LAST flag is prematurely attached to a capture buffer,
when there are no buffers in m2m source queue. But, in this scenario
even though the source buffers are returned to client, hardware might
still need to process the pending capture buffers.

Attaching LAST flag prematurely can result in the capture buffer being
removed from the destination queue before the hardware has finished
processing it, causing issues when the buffer is eventually returned by
the hardware.

To prevent this, remove the m2m API usage in stop handling.

Link: https://lore.kernel.org/linux-media/20251102-iris-drain-fix-v1-1-7f88d187fb48@oss.qualcomm.com/
Fixes: d091007 ("media: iris: add support for drain sequence")
Fixes: 75db90a ("media: iris: Add support for drain sequence in encoder video device")
Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>

On SM8250 (IRIS2) with firmware older than 1.0.087, the firmware could
not handle a dummy device address for EOS buffers, so a NULL device
address is sent instead. The existing check used IS_V6() alongside a
firmware version gate:

    if (IS_V6(core) && is_fw_rev_or_older(core, 1, 0, 87))
        fdata.device_addr = 0;
    else
	fdata.device_addr = 0xdeadb000;

However, SC7280 which is also V6, uses a firmware string of the form
"1.0.<commit-hash>", which the version parser translates to 1.0.0. This
unintentionally satisfies the `is_fw_rev_or_older(..., 1, 0, 87)`
condition on SC7280. Combined with IS_V6() matching there as well, the
quirk is incorrectly applied to SC7280, causing VP9 decode failures.

Constrain the check to IRIS2 (SM8250) only, which is the only platform
that needed this quirk, by replacing IS_V6() with IS_IRIS2(). This
restores correct behavior on SC7280 (no forced NULL EOS buffer address).

Link: https://lore.kernel.org/linux-arm-msm/20251125-venus-vp9-fix-v2-1-8bfcea128b95@oss.qualcomm.com/
Fixes: 47f867c ("media: venus: fix EOS handling in decoder stop command")
Cc: stable@vger.kernel.org
Reported-by: Mecid <mecid@mecomediagroup.de>
Closes: qualcomm-linux/kernel-topics#222
Co-developed-by: Renjiang Han <renjiang.han@oss.qualcomm.com>
Signed-off-by: Renjiang Han <renjiang.han@oss.qualcomm.com>
Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
Tested-by: Renjiang Han <renjiang.han@oss.qualcomm.com>

Introduce a new pixel format, V4L2_PIX_FMT_AV1, to the
Video4Linux2(V4L2) API. This format is intended for AV1
bitstreams in stateful decoding/encoding workflows.
The fourcc code 'AV10' is used to distinguish
this format from the existing V4L2_PIX_FMT_AV1_FRAME,
which is used for stateless AV1 decoder implementation.

Link: https://lore.kernel.org/all/20251210-av1d_stateful_v3-v10-1-cf4379a3dcff@oss.qualcomm.com/
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Deepa Guthyappa Madivalara <deepa.madivalara@oss.qualcomm.com>

…ll_fmtdesc()

Add a descriptive string for the AV1 pixel format to v4l_fill_fmtdesc(),
enabling proper reporting of AV1 support via VIDIOC_ENUM_FMT.

Link: https://lore.kernel.org/all/20251210-av1d_stateful_v3-v10-2-cf4379a3dcff@oss.qualcomm.com/
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Deepa Guthyappa Madivalara <deepa.madivalara@oss.qualcomm.com>

Extend iris decoder driver to support format V4L2_PIX_FMT_AV1.
This change updates the format enumeration (VIDIOC_ENUM_FMT)
and allows setting AV1 format via VIDIOC_S_FMT for gen2 and beyond.
Gen1 iris hardware decoder does not support AV1 format.

Link: https://lore.kernel.org/all/20251210-av1d_stateful_v3-v10-3-cf4379a3dcff@oss.qualcomm.com/
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
Signed-off-by: Deepa Guthyappa Madivalara <deepa.madivalara@oss.qualcomm.com>

…properties

Defining platform specific capabilities specific to AV1 decoder.
Set and subscribe to manadatory properties to firmware for AV1.

Link: https://lore.kernel.org/all/20251210-av1d_stateful_v3-v10-4-cf4379a3dcff@oss.qualcomm.com/
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
Signed-off-by: Deepa Guthyappa Madivalara <deepa.madivalara@oss.qualcomm.com>

Implement internal buffer count and size calculations for AV1 decoder
for all the buffer types required by the AV1 decoder, including BIN,
COMV, PERSIST, LINE, and PARTIAL.

This ensures the hardware decoder has properly allocated memory for AV1
decoding operations, enabling correct AV1 video playback.

Link: https://lore.kernel.org/all/20251210-av1d_stateful_v3-v10-5-cf4379a3dcff@oss.qualcomm.com/
Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
Signed-off-by: Deepa Guthyappa Madivalara <deepa.madivalara@oss.qualcomm.com>

…o codec binding

Kaanapali SOC brings in the new generation of video IP i.e iris4. When
compared to previous generation, iris3x, it has,
- separate power domains for stream and pixel processing hardware blocks
  (bse and vpp).
- additional power domain for apv codec.
- power domains for individual pipes (VPPx).
- different clocks and reset lines.

Iommus include all the different stream-ids which can be possibly
generated by vpu4 video hardware in both secure and non secure execution
mode.
The vpu have reserved iova, i.e some portion of the addressable range is
reserved for IO registers. Iris_resv would describe the acceptable
address range.

Link: https://lore.kernel.org/linux-media/20251017-knp_video-v2-1-f568ce1a4be3@oss.qualcomm.com/
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

vpu4 depends on more than one clock source. Thus far hardware versions
up to vpu3x have been clocked by a single source.
This adds support for multiple clocks by,
- Adding a lookup table
- Configuring OPP table for video device with different video clocks
- Setting OPP for multiple clocks during dev_pm_opp_set_opp()

This patch extends the support for multiple clocks in driver, which
would be used in subsequent patch for kaanapali, when the platform data
is prepared.

Link: https://lore.kernel.org/linux-media/20251210-knp_video-v4-1-8d11d840358a@oss.qualcomm.com/
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

…(CP) configs

vpu4 needs an additional configuration with respect to CP regions. Make
the CP configuration as array such that the multiple configuration can be
managed per platform.

Link: https://lore.kernel.org/linux-media/20251210-knp_video-v4-2-8d11d840358a@oss.qualcomm.com/
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

Introduces vp4 buffer size calculation for both encoder and decoder.
Reuse the buffer size calculation which are common, while adding the
vpu4 ones separately.

Link: https://lore.kernel.org/linux-media/20251210-knp_video-v4-3-8d11d840358a@oss.qualcomm.com/
Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

Some of vpu4 register defines are common with vpu3x. Move those into the
common register defines header. This is done to reuse the defines for
vpu4 in subsequent patch which enables the power sequence for vpu4.

Link: https://lore.kernel.org/linux-media/20251210-knp_video-v4-4-8d11d840358a@oss.qualcomm.com/
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
Co-developed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>

Some of the sequence and calculations for vpu4 is identical to vpu35,
namely power sequence for vpu controller and the clock frequency
calculation. Move those to common file that can be shared for both vpu35
and vpu4. This patch prepares for power sequence for vpu4 which is added
in subsequent patch.

Link: https://lore.kernel.org/linux-media/20251210-knp_video-v4-5-8d11d840358a@oss.qualcomm.com/
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

Add power sequence for vpu4 by reusing from previous generation wherever
possible. Hook up vpu4 op with vpu4 specific implemtation or resue from
earlier generation wherever feasible, like clock calculation in this
case.

Link: https://lore.kernel.org/linux-media/20251210-knp_video-v4-6-8d11d840358a@oss.qualcomm.com/
Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

# Conflicts:
#	Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml

# Conflicts:
#	arch/arm64/boot/dts/qcom/Makefile

# Conflicts:
#	include/linux/firmware/qcom/qcom_scm.h

Adding merge log file and topic_SHA1 file

Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>